ci(ci): add infra for maintenance branches#492
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Dependency License Review
License distribution
Excluded packages
|
There was a problem hiding this comment.
Pull request overview
Adds CI/release support for package-scoped maintenance branches (release/**) so older major lines can receive backported fixes and publish under a dedicated npm dist-tag.
Changes:
- Pass a channel-derived npm dist-tag into the publish script from semantic-release configs.
- Extend GitHub Actions workflows to run on
release/**and to diff against the PR’s actual base ref. - Add a helper script + contributing docs for creating and operating maintenance branches.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| web-packages/ap-chat/.releaserc.json | Publish with a branch/channel-specific dist-tag for maintenance releases. |
| packages/apollo-wind/.releaserc.json | Same dist-tag publishing change. |
| packages/apollo-react/.releaserc.json | Same dist-tag publishing change. |
| packages/apollo-core/.releaserc.json | Same dist-tag publishing change. |
| scripts/create-maintenance-branch.sh | New automation script to create/configure maintenance branches from tags. |
| CONTRIBUTING.md | Documents the maintenance release workflow (branching, backports, installs). |
| .github/workflows/release.yml | Run releases on release/**, per-ref concurrency, skip-ci guard. |
| .github/workflows/pr-checks.yml | Run PR checks for PRs targeting release/**; diff vs dynamic base ref. |
| .github/workflows/dev-publish.yml | Enable dev publish for release/**; diff vs dynamic base ref. |
| .github/workflows/dev-cleanup.yml | Enable cleanup for release/**; checkout dynamic base ref. |
a08eea2 to
a15c7c4
Compare
PR Review — Maintenance Branch InfrastructureReviewed the full CI/CD setup (all 14 workflows, all What looks good
Items worth discussing1. Workflows not updated — intentional? These workflows still only trigger on
Most of these seem intentionally scoped to 2. Branch protection for The CONTRIBUTING.md docs show both PR-based and direct-push workflows for maintenance branches. If 3. No automated test for the helper script
VerdictLooks good to me. The only thing I'd want confirmed before approving is item #1 — whether the CodeQL/security-scan omission is a conscious choice. |
a15c7c4 to
6de4ef3
Compare
.releaserc.json(4 files) — Added --tag ${nextRelease.channel || 'latest'} to publishCmd. No-op on main, passes correct dist-tag on maintenance branches.release.yml— Addedrelease/**trigger, per-ref concurrency group, [skip ci] job guard.pr-checks.yml— Addedrelease/**target, replaced 2 hardcodedorigin/mainrefs withorigin/${{ github.event.pull_request.base.ref }}.dev-publish.yml— Addedrelease/**target, replaced hardcodedorigin/mainwith dynamic base ref.dev-cleanup.yml— Addedrelease/**target, replaced hardcodedref: maincheckout with dynamic base ref.scripts/create-maintenance-branch.sh(new) — Helper script to automate branch creation from a tag with .releaserc.json configuration.CONTRIBUTING.md— Added "Maintenance Releases" section documenting the full workflow.